go堆内存分配

图解 Go GCmutator 申请内存是以应用视角来看问题，我需要的是某一个 struct，某一个 slice 对应的内存，这与从操作系统中获取内存的接口（比如mmap）之间还有一个鸿沟。需要由 allocator 进行映射与转换，将以“块”来看待的内存与以“对象”来看待的内存进行映射。在现代 CPU 上，我们还要考虑内存分配本身的效率问题，应用执行期间小对象会不断地生成与销毁，如果每一次对象的分配与释放都需要与操作系统交互，那么成本是很高的。这需要在应用层设计好内存分配的多级缓存，尽量减少小对象高频创建与销毁时的锁竞争，这个问题在传统的 C/C++ 语言中已经有了解法，那就是 tcmalloc

一文彻底理解Go语言栈内存/堆内存

Go内存管理一文足矣内存分配一般有三种方式：静态存储区（根对象、静态变量、常量）、栈（函数中的临时局部变量）、堆（malloc、new等）；一般最常讨论的是栈和堆，栈的特点可以认为是线性内存，管理简单，分配比堆上更快，栈上分配的内存一般不需要程序员关心。因为堆区是多个线程共用的，所以就需要一套机制来进行分配（考虑内存碎片、公平性、冲突解决）；

解决思路

如果想在heap上分配更多的空间，只需要请求系统由低像高移动brk指针，并把对应的内存首地址返回，释放内存时，只需要向下移动brk指针即可。在Linux和unix系统中，我们这里就调用sbrk（）方法来操纵brk指针：

假设我们现在申请了两块内存，A/B，B在A的后面，如果这时候用户想将A释放，这时候brk指针在B的末尾处，那么如果简单的移动brk指针，就会对B进行破坏，所以对于A区域，我们不能直接还给操作系统，而是等B也同时被释放时再还给操作系统，同时也可以把A作为一个缓存，等下次有小于等于A区域的内存需要申请时，可以直接使用A内存，也可以将AB进行合并来统一分配。

所以将内存按照块的结构来进行划分，使用链表的方式来管理，那么除了本身用户申请的内存区域外，还需要一些额外的信息来记录块的大小、下一个块的位置，当前块是否在使用。

为了支持多线程并发访问内存，使用全局锁。到目前为止

但这个内存分配器也存在几个严重的问题：

主要是以下几个思想：

在 TCMalloc（Thread Cache Memory alloc） 18张图解密新时代内存分配器TCMalloc基本概念

TCMalloc三层逻辑架构

Go 的内存分配器基于 Thread-Cache Malloc (tcmalloc) ，tcmalloc 为每个线程实现了一个本地缓存， 区分了小对象（小于 32kb）和大对象分配两种分配类型，其管理的内存单元称为 span。但与 tcmalloc 存在一定差异。

我们可以将内存分配的路径与 CPU 的多级缓存作类比，这里 mcache 内部的 tiny 可以类比为 L1 cache，而 alloc 数组中的元素可以类比为 L2 cache，全局的 mheap.mcentral 结构为 L3 cache，mheap.arenas 是 L4，L4 是以页为单位将内存向下派发的，由 pageAlloc 来管理 arena 中的空闲内存。如果 L4 也没法满足我们的内存分配需求，那我们就需要向操作系统去要内存了。

在 Go 语言中，根据对象中是否有指针以及对象的大小，将内存分配过程分为三类：

arenas 是 Go 向操作系统申请内存时的最小单位，每个 arena 为 64MB 大小，在内存中可以部分连续，但整体是个稀疏结构。单个 arena 会被切分成以 8KB 为单位的 page，一个或多个 page 可以组成一个 mspan，每个 mspan 可以按照 sizeclass 再划分成多个 element。同样大小的 mspan 又分为 scan 和 noscan 两种，分别对应内部有指针的 object 和内部没有指针的 object。

普通应用程序是调用 malloc 或者 mmap，向 OS 申请内存；而 Go 程序是通过 Go 运行时申请内存，Go 运行时会向 OS 申请一大块内存，然后自己进行管理。Go 应用程序分配内存时是直接找 Go 运行时，这样 Go 运行时才能对内存空间进行跟踪，最后做好内存垃圾回收的工作。Go 运行时把这个大块内存称为 arena 区域，其中又划分为 8KB 大小页。

在 Go 的内存管理机制中，有几个重要的数据结构需要关注，分别是 mspan、heapArena、mcache、mcentral 以及 mheap。其中，mspan 和 heapArena 维护了 Go 的虚拟内存布局，而 mcache、mcentral 以及 mheap 则构成了 Go 的三层内存管理器。

这些数据都是通过在 runtime.mksizeclasses.go 中计算得到的。Go 在分配的时候，是通过控制每个 spanClass 场景下的最大浪费率，来保障堆内存在 GC 时的碎片率的。

Golang为每个线程分配了span的缓存，即mcache，每个层级的span都会在mcache中保存一份（macache包含所有规格的span），避免多线程申请内存时不断的加锁。当 mcache 没有可用空间时，从 mcentral 的 mspans 列表获取一个新的所需大小规格的 mspan。

从mcentral数据结构可见，每个mcentral对象只管理特定的class规格的span，事实上每种class都会对应一个mcentral，主要作用是为mcache提供切分好的mspan资源。

Go 使用 mheap 对象管理堆，只有一个全局变量（mheap 也是go gc 工作的地方）。持有虚拟地址空间。mheap 存储了 mcentral 的数组。这个数组包含了各个的 span 规格的 mcentral（mcentral的个数是67x2=134，也是针对有指针和无指针对象分别处理）。由于我们有各个规格的 span 的 mcentral，当一个 mcache 从 mcentral 申请 mspan 时，只需要在独立的 mcentral 级别中使用锁，其它任何 mcache 在同一时间申请不同大小规格的 mspan 互不影响。

当 mcentral 列表为空时，mcentral 从 mheap 获取一系列页用于需要的大小规格的 span。

操作系统是按page管理内存的，同样Go语言也是也是按page管理内存的，1page为8KB，保证了和操作系统一致。page由 page allocator 管理，pageAlloc在 Go 语言中迭代了多个版本，从简单的 freelist 结构，到 treap 结构，再到现在最新版本的 radix 结构，它的查找时间复杂度也从 O(N) -> O(log(n)) -> O(1)。

从os 拿到的页内存按块管理，空闲块一般由空闲链表来管理：维护一个类似链表的数据结构。当用户程序申请内存时，空闲链表分配器会依次遍历空闲的内存块，找到足够大的内存，然后申请新的资源并修改链表。因为分配内存时需要遍历链表，所以它的时间复杂度就是 O(n)，为了提高效率，将内存分割成多个链表，每个链表中的内存块大小相同（不同链表不同），申请内存时先找到满足条件的链表，再从链表中选择合适的内存块，减少了需要遍历的内存块数量。

Go 的内存管理基本单元是 mspan，每个 mspan 中会维护着一块连续的虚拟内存空间，内存的起始地址由 startAddr 来记录。每个 mspan 存储的内存空间大小都是内存页的整数倍，由 npages 来保存。Go 的内存页大小设置的是 8KB。

9张图轻松吃透Go内存管理单元Go是按页page8KB为最小单位分配内存的吗？当然不是，如果这样的话会导致内存使用率不高。Go内存管理单元mspan通常由N个且连续的page组成，会把mspan再拆解为更小粒度的单位object。object和object之间构成一个链表（FreeList），object的具体大小由sizeclass决定，mspan结构体上维护一个sizeclass的字段（实际叫spanclass）。PS：mspan通常由N个且连续的page组成，所以可以视为一段连续内存，内部又按统一大小的object 分配，所以可以认为：mspan是 npages 整存，object 零取。

所谓申请内存，是申请 size 大小的内存，参数是size。 ThreadCache 和 TransferCacheManager 维护了 特定几个大小的 object，要做的事情就是个根据size 快速从合适的链表选择空闲内存块/object。

mspan 关键字段

heapArena 的结构相当于 Go 的一个内存块，在 x86-64 架构下的 Linux 系统上，一个 heapArena 维护的内存空间大小是 64MB。该结构中存放了 ArenaSize/PageSize 长度的 mspan 数组，heapArena 结构的 spans 变量，用来精确管理每一个内存页。而整个 arena 内存空间的基址则存放在 zeroedBase 中。heapArena 结构的部分定义如下：

Go 整体的虚拟内存布局是存放在 mheap 中的一个 heapArena 的二维数组。定义如下：

堆上所有的对象都会通过调用 runtime.newobject 函数分配内存，runtime.newobject 就是内存分配的核心入口，该函数会调用 runtime.mallocgc 分配指定大小的内存空间。